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This paper provides an outline of a formal approach that we are developing for modelling Virtual Or- 
ganisations (VOs) and their Breeding Environments (VBEs). We propose different levels of represen- 
tation for the functional structures and processes that VBEs and VOs involve, which are independent 
of the specificities of the infrastructures (organisational and technical) that support the functioning 
of VBEs. This allows us to reason about properties of tasks performed within VBEs and services 
provided through VOs without committing to the way in which they are implemented. 

1 Introduction 

This paper reports on on-going work towards a formal approach for modelling virtual organisations 
(VOs) and their breeding environments (VBEs) in the sense of [lOl. A VBE defines a base long-term 
cooperation agreement among a number of participants (individuals or institutions) and characterizes 
their interoperable infrastructure As such, a VBE represents the organisational context in which the 
creation and operation of VOs takes place; VOs are seen as ensembles that are formed dynamically to 
provide high-level functionalities, or services, by sharing a number of resources in a distributed way, 
using the new connectivity environments that are being made available through Global 1.15,1 and Grid 
Computing [14]. 

The purpose of developing a formal modelling approach echoes the challenge of building "Verifiable 
VOs" as raised in [7|. This implies that our approach is unavoidably partial: as in any formal account of 
the real world (which includes business), we need to operate on abstractions that are amenable to some 
form of mathematical representation and analysis. Our approach defines different levels of representation 
of VBEs, VOs and their activities, which are essential for supporting several forms of analysis, from the 
properties of the coordination structures that are put in place through policies and workflows to the 
management of the resources that are shared within a VBE and used by their VOs. 

There are multiple levels of abstraction at which formal methods can operate. In this paper, we ab- 
stract from the specificities of the infrastructures (organisational and technical, including IT) that support 
the functioning of VBEs: we aim for an 'infrastructure-agnostic' account of the functional structures and 
processes that VBEs and VOs involve. We concentrate on the functional and behavioural aspects in 
which partners and resources are involved without committing to the way in which they are effectively 
implemented. Therefore, we do not model the brokers (human or software) that procure services that 
can be used to create business or the communication networks that support interconnectivity — what we 
could call the VBE middleware. 

We are also aware that the model that we present in this paper misses several aspects of VBEs. For 
instance, we do not address at present the decision-making processes through which VOs are created 
within a VBE or the actual business goals that preside to the creation of a VBE (see ifTTi for an overview 
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of some of the formal approaches that have been proposed to address these issues). However, we do 
intend that the formal models that we propose can be used to inform such processes, for instance by sup- 
porting stochastic analysis on the usage that VOs can make on VBE resources or validation of functional 
properties that VOs offer through services, something that we are leaving for future work. 

Our approach supports the definition of a structural and behavioural model of a fixed VBE based on 
three different levels of representation: (1) the definition of the persistent functionalities of the VBE; 
(2) the definition of the transient functionalities of the VOs that are offered by the VBE at a specific 
moment in time, what we call a business configuration of the VBE; and (3) the ensemble of components 
(instances) and connectors that, at that time, deliver the services offered by the VOs present in the busi- 
ness configuration, what we call a state configuration. These levels are not 'architectural layers': they 
do not contain entities that interact with entities in other layers. Rather, they represent a hierarchy of 
representations at a fixed time: the first level is invariant, i.e. it provides a representation of those aspects 
of a VBE that will not change; the business configuration at the level below captures the way the VBE is 
logically organised at that time in terms of VOs; the state configuration represents the actual 'physical' 
instances of the VOs that are currently operational, i.e. which specific services are currently being pro- 
vided within the VBE. 'Real' entities are only represented in state configurations: the other levels deal 
only with types of entities. 

More specifically, the three levels of representation are modelled as follows: 

• A VBE consist of (1) a collection of resources; (2) a consortium of (persistent) partners; (3) a 
number of policies constraining the way resources can be shared and the partners agree to do 
business together, including rules for the consortium to expand for establishing specific VOs; and 
(4) a number of supporting tasks that operate processes (management or otherwise) that serve the 
roles enacted within the VBE. These constituent elements are invariant, i.e. they are present in 
every business configuration of the VBE (in the sense explained below). 

• The current business configuration of a VBE, is understood as (1) the collection of additional 
(non-permanent) partners, that we call associates, and resources that are part of the VBE; (2) the 
tasks that support the roles of the new partners and their resources; (3) the VOs that the VBE 
currently supports; and (4) the policies that apply to their instantiation and their coordination at 
any given time. Tasks and VOs may rely on complementary, transient partners (which we call 
'associates') that join the VBE to provide specific business services and remain in the VBE only 
while those services are required. Associates can be fixed at VO-creation time or discovered on 
the fly when needed, subject to service-level agreements, in order to be able to accommodate the 
needs of specific clients. 

• The current state configuration of a VBE consists of 'components', coimected through 'wires', 
that joinfly operate the tasks and the services offered by the VOs that are running in the current 

state. These components include the shared resources of the VBE as well as those that are brought 
into the VBE by the associates. The topology of the configuration (the way components are wired 
together) reflects the policies established at the level of the current business configuration. At 
this level, one can determine levels of resource consumption or properties of a number of other 
parameters, including measures of quality of service. 
Part of the importance of distinguishing between these three levels is that we can account for two different 
kinds of change (admitting that the VBE level is invariant, the creation of which we do not model at 
present): 

• Changes in the business configuration reflect the creation or deletion of tasks or VOs. Creating 
a new VO may involve identifying associates or the criteria that will need to be observed for 
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discovering such associates on the fly, depending on the nature of the customers that procure the 
service (in which case each service may involve different associates). Deleting a VO requires 
that the current state configuration is in a quiescent state relative to that VO, i.e. that none of 
the services offered by the VO is currently active. Changes at this level are triggered by business 
concerns (which we do not model at present). 

• Changes to the state configuration result from the launching of (instances of) tasks or of services 
provided by one of the VOs present in the business configuration, which dynamically adds (or 
removes) components or wires to (from) the current state configuration. Changes at this level 
are triggered by the actions performed by or through the components and the communications 
exchanged through the wires that connect them. 

Given the way levels are organised, these changes take place in different 'timebands' in the sense of jSl, 
i.e. the levels induce different granularities of time: the state-configuration changes take place within a 
fixed business configuration, meaning that business configurations induce a coarser time scale. 

Given the limited space available, we focus only on the VBE and business configuration levels. In the 
sequel, we outline the formalisms and methodology that we are proposing for each level of representation 
and change, which we have adapted (and extended) from recent work on service-oriented modelling 
lfT2llT3ll . Essentially, we use graph-based representations to formalise and establish relationships between 
the two levels — logic/process-based formalisms for the specification of activities and services. 

2 A Model of Virtual Organisation Breeding Environments 

As already mentioned, we see a VO as a dynamic ensemble of entities that operate over a communication 
and collaboration network through which they can share resources to offer services. Some of those 
entities and resources are provided by the VBE in which the VO was created; others are external to the 
VBE and co-opted or procured to satisfy the business goal of that particular VO. We define a (formal 
model of a) VBE to consist of: 

• A collection of persistent partners, where a partner consists of: 

- Its name (individual or organisation, virtual or not); 

- A collection of attributes through which policies can be defined on the involvement of the 
partner in business configurations. 

• A collection of persistent resources where a resource consists of: 

- Its identifier; 

- A collection of attributes through which the usage of the identified resource can be monitored. 

• A collection of policies expressed over partners and resources that apply to all business configura- 
tions of the VBE. 

• A collection of tasks that support the roles enacted within the VBE. A task is defined by a task- 
module consisting of: 

- Component specifications that are used in state configurations as interfaces to the partners 
(in which they are called serves-interfaces) or resources (in which they are called uses- 
interfaces) involved in the task; 

- Specifications of components and wires that jointly orchestrate the task. 
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- Mappings from the serves-interfaces (resp. uses-interfaces) to the partners (resp. resources) 
of the VBE complete the task definition. 

Notice that we separate the task-module from the way it is used in the VBE. Effectively, task-modules 
are design primitives that define patterns that can be reused in the definition of VBEs. 

As an example, we use a very simple scenario: a group of hotels, a car rental company and a guided- 
tour company decide to create a VBE — visitUs — to promote tourism in the local town. 

• The partners of visitUs are the hotels (to make the example shorter, we model the case of two hotels, 
grandHO and centralHO), the car rental agency carHI and the guided-tour company tourAG; 

• The resources include two systems: registrationSY supporting management activities of visitUs 
and a shared reservation system reservationSY supporting the business purpose (hotel bookings 
and so on). 

• The policies establish criteria for the admission of transient partners (e.g. they need to operate 
within a given vicinity) and the use of the shared resources (e.g. the cost of maintaining the reser- 
vation system), for which their interfaces need to include parameters that capture these properties. 
The policies are expressed as first-order expression in the language of the parameters and the cor- 
responding data types. 

• The tasks include the process managerRO that supports the administrator role performed by grandHO, 
which connects to the registration system, and the process memberRO that allows each partner to 
use the reservation system. (Other roles might have been considered as discussed in ifTTl .) 

We use a graphical notation to depict task modules as illustrated in Figure [T] for the task managerRO 
that supports the administrator of visitUs. The specification of the component MO that orchestrates the 
task is Management Orchestrator and the wires are RM and MR. The specification of the serves-interface 
MN used by grandHO - the partner who performs the managerial role - is Registry Manager, and the 
specification of the uses-interface RE (which connects to registrationSY, the resource that supports the 
task) is Registry. 



managerRO 




MO: 
Management 
Orchestrator 




Figure 1 : The task module managerRO 

We also use a graphical notation to depict VBEs, which is inspired by use-case diagrams (though our 
usage of the notation is not necessarily faithful to its original purpose). As illustrated in Figure [2| we 
use stereotypes to identify the actors that correspond to partners and resources of the VBE. Each task is 
represented by a use-case. 
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«partner» «partner» «partner» «partner» 
grandHO centralHO tourAG carHI 



visitUs 




«resource» 
registrationSY 



«resource» 
reservationSY 



Figure 2: VBE diagram for visitUS 



3 Business Configurations 

The current business configuration of a VBE defines the types of tasks and the VOs that the VBE supports 
to meet its (current) business goals. The actual process through which a VBE decides on how to configure 
itself is not part of our present model as it depends on a number of business or organisational concerns 
that the formal methods that we are illustrating do not address. However, the kinds of qualitative and 
quantitative analysis that our approach provides should be able to inform that process and corresponding 
decisions, something that we plan to address in the future. 

We define a VBE business configuration to consist of an extension of the VBE with: 

• A collection of associates (transient partners), where an associate consists of: 

- Its name (individual or organisation, virtual or not); 

- A collection of attributes through which policies can be defined on the involvement of the 
associate in the VBE. 

• A collection of transient resources, each of which consists of: 

- Its identifier; 

- A collection of attributes through which the usage of the identified resource can be monitored. 

• A collection of policies expressed over associates and their resources that apply to their involve- 
ment in the VBE (e.g. the conditions that determine the cessation of their involvement). 

• A collection of tasks that support the roles enacted by the associates within that business configu- 
ration of the VBE. 

• A collection of VOs that define the services that the VBE provides in that business configuration. 
A VO is defined by a VO module consisting of: 
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- Component specifications tliat are used in state configurations as serves-interfaces to tiie 
partners or associates, or uses-interfaces to resources involved in the VO; typically, one such 
interface serves the coordinator of the VO. 

- Component specifications that are used as requires-interfaces for external entities or as the 
provides-interface for the customers of the VO. The specification of requires-interfaces iden- 
tifies the behavioural properties that are expected of external parties to be eligible to be 
chosen as service providers for the VO. The specification of the provides-interface identifies 
the properties that customers can expect of the service offered by the module. 

- Specifications of the components and wires that model the (possibly distributed) process that 
orchestrates the services provided by the VO. 

- An internal configuration policy, which identifies the triggers of the external service discov- 
ery process as well as the initialization and termination conditions of the components and 
wires. 

- An external configuration policy, which consists of the variables and policies that determine 
the quality profile to which the discovered services need to adhere. 

- Mappings from the serves-interfaces (resp. uses-interfaces) to the partners or associates (resp. 
resources) of the VBE complete the VO definition. 

• A collection of external entities, each of which represents a partner that may need to be co-opted 
to provide a service for one of the VOs that the VBE offers in that business configuration. 

• A collection of customers, one for each of VO, each of which defines the interface (interactions 
and functional properties) that the customer of the corresponding VO can expect. 

As for tasks, VO-modules are design primitives that define patterns that can be reused in the definition of 
multiple VBE business configurations. As an example, we consider a business configuration of visitUs in 
which a travel booking service is offered through a VO named travelBK. An associate named travelAG is 
admitted as a member of the VBE for managing that VO. Services offered through travelBK may require 
an external flight agent to be discovered according to the criteria specified mflightAG. A specific agent is 
not chosen as an associate in order to maximise customer satisfaction — each customer of the VO may 
express service-level policies (e.g. preference for a particular airline, or minimum cost, or proximity) 
that will be optimised when selecting the corresponding external partner. 

We extend the diagrams used for VBEs to account for business configurations as illustrated in Figure |3] 

We use a graphical notation similar to task-modules to depict VO-modules as illustrated in Figure [4] 
for travelBK. We use the symbol w to indicate the internal configuration policy as it applies to compo- 
nents and requires interfaces, and . i". . ■ • !" for the external configuration policy. The module consists of 
a provides-interface TR for interactions with customers of the VO, a serves-interface for interactions with 
the coordinator of the VO, a uses-interface for interactions with the reservations system, and a requires- 
interface for the discovery of a flight agent. 

A more formal definition follows where each node uniquely represents a specific interface of an 
entity (e.g., institution, participant, etc.) in a business configuration rather than the entity itself. A task- 
or VO-module M defines: 

• A graph graph(M). 

• A distinguished subset of nodes uses(M)C nodes(M). 

• A distinguished subset of nodes serves(M) C nodes(M) distinct from uses(M). 
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Figure 3: VBE business configuration for visitUS 




Figure 4: The VO module travelBK 



• In the case of a VO-module, a subset of nodes requires(M) C nodes(M) distinct from uses(M) and 
serves(M). 

• In the case of a VO-module, a node provides(M)G nodes(M) distinct from requires(M), serves(M) 
and uses(M). 

• A labeUing function labelM such that: 

- labelM(n) is a component specification. 

— labelM (e : n -H- m) is a connector. 

Component specifications and connectors are discussed in Section |4] In the case of a VO-module, we 
denote by body(M) the (full) sub-graph of graph(M) that forgets the node provides(M), the nodes in 
requires(M) and the edges that connect them to the rest of the graph. That is, body(M) consists of all the 
elements that are internal to the VO. 
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A business configuration of a VBE also defines a labelled graph obtained by expanding its tasks 
and VOs with the bodies of the labelled graphs that correspond to their modules. Having such a formal 
representation for VBE configurations allows us to use graph transformations to formalise rules and 
policies to evolve the configurations, for instance the creation of new VOs. In Figure [5] we depict a 
business configuration that extends the one in Figure [3] with a new VO that offers arrangements for 
weddings as a service. 




«customer» 
traveller 



«customer» 
bride&groom 



«external» 
entertalnmentAG 



«resource» 
registrationSY 



«resource» 
reservationSY 



Figure 5: Another VBE business configuration for VisitUS 



4 Component Specifications and Connectors 

In order to account for the behaviour that, in state configurations (referred to as level 3 in Section 1), 
emerges from the interconnections established inside the ensembles that perform tasks or deliver services 
through VOs, we need a uniform representation of the entities and resources involved, which in our 
approach we do in terms of component and wire specifications. A component specification is a pair 
{signature, behaviour) where: 

• Signature declares the interactions in which the component may be involved. 

• Behaviour is a formal model of the behaviour of the entity that the component represents expressed 
in terms of the interactions identified in the signature and a number of parameters that reflect 
resource consumption or quality-of-service attributes. 

Given the space available, we are not able to define in detail the formalisms that we use in component 
specifications (these are similar to those that we have proposed for the service modelling language SRML 
lfT2l ). We discuss below the provides-interface of travelBK, which is of type Customer. This specifica- 
tion is what we call a business protocol: it uses patterns of typical business conversations, which are 
abbreviations of sentences of a temporal logic that we have adopted for service-oriented modelling 
The remaining specifications can be found in the Appendix. 
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In the formalism that we adopt, interactions can be either synchronous or asynchronous, one-way or 
two-way (i.e. conversational): 

• s&r/r&s — conversational asynchronous interaction where the initiating party expects a reply from 
its co-party 

• rcv/snd — one-way asynchronous receive/send 

• ask/rpl — synchronization with the co-party to obtain/transmit data 

• tll/prf — blocking requests to the co-party to perform an operation 

In our example, the interface that travelBK offers to its customers specifies that the VO can engage in 
the interaction bookTrip (initiated by the customer) and send payNotify and refund to the customer. 

BUSINESS PROTOCOL Customer is 
INTERACTIONS 
r&s bookTrip 

Q> from, to : airport, out, in : date 

fconf : fcode, hconf : hcode, amount : moneyvalue 
snd payNotify 

H status : boot 
snd refund 

amount : moneyvalue 
SLA VARIABLES 

KD : [Q..\QQ],PERC: [0..100] 
BEHAVIOUR 

initiallyEnabled bookTrip &>1 

(bookTrip ^/\ bookTrip /?) ensures payNotify &\ 

[payNotify &\ A payNotify. status) enables bookTrip "fr? until today ^ KD < bookTrip. out 
(bookTrip 'v'T Atoday + KD < bookTrip.out) ensures refund Qs\ 
refund.amount > bookTrip. amount * PERC / 100 after refund 6 ! 

Interactions of type r&s and s&r are conversational (in the sense of S), i.e. they involve a number 
of events exchanged between the two parties: 



interaction^ 


The event of initiating interaction. 


interaction^ 


The reply-event of interaction. 


interaction/ 


The commit-event of interaction. 


interactionX 


The cancel-event of interaction. 


interaction'Ti' 


The revoke-event of interaction. 



The meaning of these events should be self-explanatory: the reply-event is sent by the co-party, 
offering a deal or declining to offer one; in the first case, the party that initiated the conversation may 
either commit to the deal or cancel the interaction; after committing, the party can still revoke the deal, 
triggering a compensation mechanism. Events can have several parameters (for instance, the initiation 
event bookTripQ> carries data about airports and dates), and the corresponding reply event bookTripM 
carries reservation codes for the flight and the hotel as well as the total cost). 

These events are used as atomic formulae in the language that we use to specify the properties that 
a customer can expect from the service. For instance, the first property specifies that the VO is ready to 
receive the initiation event of BookTrip. The second property says that a commit event received during 
the validity period of the booking entitles the customer to receive a pay confirmation. 
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The declaration of the interactions in a signature is local to the component, i.e. all interaction names 
are local. This implies that there are no implicit relationships between components that result from the 
accidental of the same name: all interconnections are externalised instead in what we call 'wires'. A 
wire defines a connector through which two components can be interconnected so that they can interact. 
More specifically, a connector |[Il|T8l is a triple {roleA,Glue,roleB) where wleA and wleB are signatures 
and Glue defines the protocol that coordinates the interactions identified in wleA and roleB — this may 
include routing events, superposing protocols for secure communication, or transforming sent data to the 
format expected by the receiver, inter alia. A wire interconnects two components through the connector 
by mapping wleA to one component and roleB to the other. 

Service-level agreements are negotiated through policies using the c-semiring approach to constraint 
satisfaction and optimisation [5|. An example of a policy is: 



The policy expresses that percentage p of the cost that is refundable (transmitted to the customer 
through the SLA variable TR.PERC) is bounded by the least of 90% and a linear function of the period 
d during which the deal can be revoked, which is established by the VO coordinator through the variable 
TC.KD. 

5 Concluding Remarks and Further Work 

In this paper, we have outlined a formal approach that we are defining for modelling structural and 
behavioural aspects of VBEs and VOs. Several levels of representation are proposed for VBEs that 
distinguish between (1) the persistent aspects of VBEs in terms of members, resources and tasks that 
involve them, (2) the possible business configurations of VBEs characterised in terms of the VOs that it 
creates to provide services and the additional (associate) members that are involved in the VOs, and (3) 
the state configurations of VBEs, which result from the services (instants) offered by the VOs at a given 
state. 

From a formal point of view, these levels of representation are graphs whose nodes are component 
specifications and the edges (wires) are connectors. Component specifications provide either interfaces 
for partners and resources to be involved in tasks and services offered through VOs, or orchestrations of 
those services, or requirements for external services, or properties offered to customers of VOs. Choosing 
graphs as formal models allow us to use techniques that have been proposed for formalising architectural 
aspects of system structure and evolution (e.g. |[T3l WJl ) in order to account fort he evolution of VBE 
business configurations (as VOs are added, deleted or modified) and also their configuration states (as 
new services are created and bound to customers). 

As formalisms for specification, we are using those put forward for service-oriented modelling in the 
SENSORIA project lUlEllIll- Together with the graph-based representation of business configurations, 
these formalisms can be used for inferring emergent properties of VOs. Model-checking techniques 
have been used for verifying properties offered by services [3|, which we plan to extend to VOs. The 
proposed formal model also supports forms of quantitative analysis using the stochastic analyser PEPA 
161 [161, which we intend to extend to VOs. Negotiation of service-level agreements is supported by 
techniques for constraint optimisation ||5l, which again we plan to use for the discovery of services from 
external partners that VOs may require. 



{TC.KD,TR.PERC} 




1 ifde[0..100]andl < d and p < 90 and p<50+5*d 
0, otherwise 
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Appendix - The TravelBK VO-module 




TravelBK consists of: 

• TR - the provides-interface of the module, of type Customer, 

• FA - a requires-interface (for a flight-booking service), of type FlightAgent; 

• RO - the component that orchestrates the business process, of type TravelOrchestrator; 

• RV - a uses-interface for a resource that provides a registration system, of type Reservations; 

• TC - a serves-interface for the partner that plays the role of coordinator of the VO, of type 
TravelCoordinator; 

• TO, RB, RF, RT - wire-interfaces typed by connectors that establish the required interconnections. 

VO TravelBK is 

COMPONENTS 

RO: TravelOrchestrator 

intRO , init: s=START A hconf=NILL 
intROCyterm: s=END_UNBOOKED 

V (s=CONFIRMED A today>bookTr ip . out ) V s=END_COMPENSATED 

PROVIDES 



TR: 


Customer 


REQUIRES 




FA: 


FlightAgent 




intFA trigger: hconf=hcode 


SERVES 




TC: 


TravelCoordinator 


USES 





RV: Reservations 
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EXTERNAL POLICY (partial) 



SIA VARIABLES 

TC.KD, TR.PERC, FA. MAX, TR . KD 
CONSTRAINTS 

Ci : {TC.getFlightCoiranission(FA. serviceld) , FA. MAX} 
fl if d < p 



def,(d,p) = 



otherwise 



C2: {TC.KD, TR.PERC} 

[1 if d e [0..100] and 1 s d and p s 90 and p s 50 + 5 * d 

otherwise 



def2(d,p) = 



WIRES (partial) 



TR 

Customer 


Ci 


TO 


di 


RO 

TravelOrchestrator 


s&r bookTrip 


Si 




Ri 


r&s bookTrip 


6 from 


ii 




ii 


6 from 


to 


12 




12 


to 


out 


13 




13 


out 


in 


14 




14 


in 


traveller 


15 




is 


traveller 


travcard 


is 




ie 


travcard 


M fconf 


Ol 




Ol 


M fconf 


hconf 


O2 




02 


hconf 


amount 


O3 




03 


amount 


rev refund 
6 amount 


Ri 
ii 




Si 
ii 


snd ackRefundSnd 
6 amount 



RO 




RF 




FA 


TravelOrchestrator 


C2 


d2 


FlightAgent 


sfir bookFlight 


Si 




Ri 


rSs lockFlight 


Qi from 


ii 




ii 


6 from 


to 


i2 




i2 


to 


out 


i3 




i-3 


out 


in 


i4 




i-i 


in 


traveller 


is 




is 


traveller 


M fconf 


Ol 




Ol 


K fconf 


amount 


02 




02 


amount 
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LAYER PROTOCOL TravelCoordinator is 



INTERACTIONS 

rpl getFlightCommission{FAid: serviceld) :moneyvalue 



LAXER PROTOCOL Reservations is 



INTERACTIONS 

rpl availability (out, in: date) :hcode 
prf book ( hconf : hcode ) 
prf cancel ( hconf : hcode ) 



BUSINESS ROLE TravelOrchestrator is 



INTERACTIONS 

rSs bookTrip 

& from , to : airport , 
out , in ; date , 
tr ave ller : us rdata 
travcard ; paydata 
fconf:fcode, 
hconf ; hcode, 
amount : money value 
ask f indHotel ( out , in : date ) : hcode 
til bookHotel ( hconf : hcode ) 
til cancelHotel ( fconf : hcode ) 
snd ackRefundSnd 

Q, amount : money value 
s&r bookFlight 

Q, from, to: airport, 
out, in: date, 
traveller :usrdata 
E3 fconf : f code 

amount : money value 

ORCHESTRATION 

local s: [START, QUERIED, FLIGHT_OK, CONFIRMED, END_UNBOOKED , END_COMPENSATED ] , 

hconf : hcode 

transition Request 

triggeredBy bookTripA 
guardedBy s=START 
effects 

hconf '=f indHotel (bookTrip. in, bookTrip. out ) 
A hconf i^NIL D s'=QUERIED 
A hconf '=NIL D s ' =END_UNBOOKED 
sends hconf 'i'NIL D bookFlight£i 

A bookFlight . from=bookTrip. from 
A bookFlight. to=bookTrip. to 
A bookFlight. out=bookTrip. out 
A bookFlight. in=bookTrip. in 
A bookFlight . traveller=bookTrip . traveller 
A hconf '=NIL D bookTripE3 a bookTrip. Reply=False 

transition FlightAnswer 

triggeredBy bookFlightE3 
guardedBy s^QUERIED 

effects bookFlight. Reply D s'=FLIGHT_OK 
a --bookFlight. Reply D s ' =END_UNBOOKED 



transition TripCommit 

triggeredBy bookTrip*' 
guardedBy s=FLIGHT_OK 
effects s'=CONFIRMED 



bookHotel ( hconf ) 



m 
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cancelHotel ( hconf ) 



transition TripCancel 
triggeredBy bookTripX 
guardedBy s=FLIGHT_OK 
effects s ' =END_UNBOOKED 
sends bookFlight* 

transition TripCompensate 
triggeredBy bookTrip'f 

guardedBy s=CONFIRMED a today<bookTrip.out 
effects s'= END_COMPENSATED A cancelHotel ( hconf ) 
bool^^light'^ a ackRefundSndii 

transition Conf irmBookTripTimeOut 
triggeredBy nowabookTrip.UseBy 
guardedBy s=FLIGHT_OK 

effects s ' =END_UNBOOKED A cancelHotel (hconf ) 



BUSINESS PROTOCOL FlightAgent is 

INTERACTIONS 

rSs lockFlight 

Q, from, to: airport, 
out , in : date , 
traveller !usrdata 
E3 f conf ! f code 

amount : money value 

SLA VARIABLES 

KD: [0. . 100] ,PERC: [0. .100] , MAX: [0. . 100] 

BEHAVIOUR 

initiallyEnabled lockFlight3? 
lockFlighf^? enables lockFlightt? 
until today+KD £ bookTrip.out 



BUSINESS PROTOCOL Customer is 

INTERACTIONS 

s&r bookTrip 

Q, from , to ; airport , 
out , in ; date 
f conf ;f code, 
hconf :hcode, 
amount : money value 
rev refund 

& amount: money value 

SLA VARIABLES 

KD:[0..100], PERC: [0. .100] 

BEHAVIOUR 

initiallyEnabled bookTripA? 

(bookTrip! a bookTripv'? ) enables bookTripU"? 

until today+KDabookTrip . out 
(bookTrip"?? a today+KD a bookTrip.out) ensures refundfi! 
refund. amount=bookTrip.amount*PERC/100 after refundfi! 



INTERACTION PROTOCOL Straight . I ( dj ) is 

ROLE A 

snd Si 

& ii:di 

ROLE B 

rev Ri 

& ii:di 

COORDINATION 

Si = Ri 
Si.ii=Ri.ii 
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